1. Field of the Invention
This invention relates to 3rd Generation Partnership Project (3GPP) Multimedia Broadcast/Multimedia Service (MBMS), and more specifically to MBMS multicast service announcements in a cell.
2. Discussion of the Related Art
Work has been started in 3GPP to standardize multicast as a new service. The aim in this work is to enhance the current capabilities not only in Universal Terrestrial Radio Access Network (UTRAN) but also in the Core Network (CN), as well as enhancing the capabilities of providing such services. These services use the common network resources, but are intended only to a restricted group of people in a cell. These requirements are not totally fulfilled in the current Cell Broadcast concept, which is already standardized in 3GPP release 99.
FIG. 1 shows a diagram of a UTRAN architecture. The architecture includes a core network 10 which is interconnected to a UTRAN 12 which provides over air information to one or more User Equipment (UE)14, 16. The core network 10 interfaces with UTRAN 12 via one or more interfaces 26. Interfaces 26 connect core network 10 to Radio Network Controllers (RNC) 20 that reside inside a Radio Network Subsystem (RNS) 18 in the UTRAN 12. The RNS also includes one or more Node B devices 22. The Node B 22 is a logical node in the RNS responsible for radio transmission/reception in one or more cells 24 to/from the UE. An RNC 20 is interconnected to other RNC 20 by a logical interface 28. The RNC interfaces with Node B 24 via a different interface 30. RNS 18 contains one RNC and is responsible for the resources and transmission/reception in a set of cells. RNC 20 is a logical node in the RNS in charge of controlling the use and the integrity of the radio resources. UTRAN is a conceptual term identity that is part of the network which consist of RNCs and Node Bs.
One part of the point-to multipoint concept is the transmission of multicast related data to the User Equipments (UEs), which are entitled to receive such data. This transmission cannot be provided efficiently, if the UEs are not aware of the agreed multicast services (agreed by the Network (NW) and configured, e.g. by an operator) before the actual multicast data transmission starts. The lack of the multicast service announcement procedure means that all multicast capable UEs should listen to the multicast related physical channel continuously, when they are not doing anything else, in order to be ready on that time when the transmission of the service is started. From a UE power consumption point of view, this is very disadvantageous. Therefore, it is very important that along with the multicast data transmission, the NW is capable of also informing the UEs about incoming multicast services.
The goal of an announcement procedure is not just to inform the UEs about the forthcoming and ongoing services, but also to perform the scheduling and the cell resource control at the network side, e.g., that variable bit rate is supported on such channel that is transmitting multicast data packets. In practice this means that the length of the multicast service can not be estimated until all data has been receive in RNC and, therefore, no long term accurate scheduling decision can not be made or indicated to any UEs in the cell.
In order to support more flexible service announcement procedure for multicast service the service announcement can be divided into two categories: long term service announcement and the short term service announcement. The long term service announcement is a data frame, which consists of information about such multicast services, which are defined to be sent to the cell, but no final and accurate scheduling decision has been made yet (i.e. resembles e.g. the TV-guide; news at 12 o'clock, stock news at 12.15 etc). The long term service announcement can also consist of multicast service advertisements.
The short term service announcement on the contrary contains information about the services to whom the accurate transmission time can be indicated and, therefore, this kind of announcement type should be continuous.
In order to support the long term service announcement the services of the short term service announcement procedure is required.
Although currently no service announcement procedure has been defined in 3GPP especially for multicast services, the 3GPP specifications already imply the concept of cell broadcast (for which one service announcement procedure has already defined). But unfortunately this procedure is not applicable as such for multicast because this procedure assumes that the length of the service is always known when the final scheduling decision (i.e. announcement frame) is made (please note that the all bits, which belong into one cell broadcast session are transmitted to a Radio Network Controller (RNC) inside one Service Area Broadcast Protocol (SABP) Service Data Unit (PDU)). Unfortunately, the knowing of such information in the RNC for multicast is impossible due to the different nature of the multicast service. When the maximum size of the cell broadcast session is limited to the size of 1246 bytes, no such restriction can be defined for the multicast session and, therefore, also no reliable pre-estimation of duration of each multicast session on the air interface can be made.
Another problem related to multicast service announcement is the requirement that UEs which are in IDLE mode and which are, e.g., just entered into the cell, should be capable of joining the session even though the service is already on going. This kind of requirement implies that the network should indicate the multicast service scheduling situation continuously, which is currently an impossible task to do.